No dia 10 de setembro, a OpenAI disponibilizou a Agents API em beta público, "trazendo aos desenvolvedores o mesmo harness e a mesma infraestrutura que alimentam o Codex por meio de uma API simples e flexível". No DevDay, em 29 de setembro, ela ganhou o recurso de computer use, um irmão nativo da AWS e um vizinho: os novos dots sempre ativos do ChatGPT rodam sobre esse mesmo harness do Codex.
Se você ler isso como uma pessoa desenvolvedora criando um produto baseado em agentes, é uma ótima notícia: aquele harness que você provavelmente implementaria de forma improvisada agora é problema de outra pessoa. Mas se você analisar isso como um engenheiro cuja equipe já roda o Claude Code e o Codex em uma base de código real, a perspectiva muda. A API responde a: "como mantenho um agente em execução por horas?". Mas não responde a: "como minha equipe fica sabendo o que seis deles fizeram e quem aprovou o site no qual um deles acabou de fazer login?". O Sharkly existe exatamente para responder à segunda pergunta.
Resumo (TL;DR)
A Agents API hospeda o harness do Codex: sessões persistentes, compactação de contexto, busca de ferramentas (tool search), subagentes e um sandbox hospedado pela OpenAI, na sua própria infraestrutura ou em nove parceiros, sem custos adicionais além de tokens, ferramentas e tempo de contêiner. O DevDay adicionou o computer use, em que sua aplicação aprova cada nova origem de site e cada login (a aprovação de origem não equivale à confirmação de ações individuais), além do Bedrock Managed Agents, que executa suas principais capacidades dentro da AWS. Nada disso, porém, gerencia a camada de equipe: quem atribuiu a tarefa, qual agente está com ela, o que foi concluído, o que falhou e quem valida o resultado.
O que é a Agents API e o que a OpenAI executa
A visão geral da OpenAI sintetiza a API em quatro conceitos fundamentais. Um Agent (Agente) é "o modelo, as instruções, as ferramentas e os servidores MCP disponíveis para o agente". Um Environment (Ambiente) é "um sandbox ou computador opcional onde o agente acessa arquivos, carrega habilidades e executa comandos". Uma Session (Sessão) é "uma instância persistente de um agente que trabalha em tarefas e responde a entradas". Events and items (Eventos e itens) são as entradas enviadas e as saídas retornadas.
Você cria uma sessão com a configuração de um agente, envia uma tarefa assim que o ambiente estiver pronto, acompanha o andamento via streaming ou webhooks e, em seguida, pode enviar novas instruções ou direcionamentos para a mesma sessão. Veja o exemplo da documentação, resumido:
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions: "Use the docs MCP and web search. Delegate independent research to subagents when useful.",
tools: [
{ type: "programmatic_tool_calling" },
{ type: "mcp", server_label: "openai_docs", transport: { type: "http", server_url: "https://developers.openai.com/mcp" } },
{ type: "web_search" },
],
multi_agent: { enabled: true, max_concurrent_subagents: 4 },
},
environment: { type: "self_hosted", workspace_directory: "/workspace" },
input: [{ role: "user", content: [{ type: "input_text", text: "Research how to connect an MCP server to an OpenAI agent and summarize the setup." }] }],
});
Duas linhas concentram as principais novidades. multi_agent ativa a distribuição para subagentes com um limite de concorrência, e environment.type define onde o código é executado: openai_hosted, self_hosted ou em um dos sandboxes parceiros (Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel).
A documentação resume a divisão de responsabilidades em uma única frase: "A OpenAI gerencia sessões, orquestração, compactação de contexto e recuperação, enquanto a sua aplicação fornece as ferramentas e escolhe o ambiente de execução".
| A OpenAI gerencia | Você ainda precisa fornecer |
|---|---|
| O ciclo do agente: chamadas ao modelo, uso de ferramentas, novas tentativas | A tarefa e a definição de concluído (definition of done) |
| Compactação de contexto quando a sessão atinge o limite | Ferramentas: servidores MCP, funções e recursos nativos |
| Busca e carregamento de ferramentas | Credenciais, via IDs de cofre (vault IDs) |
| Decomposição e coordenação de subagentes | A escolha do ambiente e sua configuração |
| Retomada e direcionamento da sessão | Tudo o que acontece após o término da sessão |
O consumo do modelo é cobrado de acordo com as tarifas padrão da API do modelo, as ferramentas têm tarifas habituais e os sandboxes hospedados pela OpenAI são tarifados por uso de contêiner; o post de lançamento destaca que "não há taxas adicionais pelo uso da Agents API". Dois limites são destacados claramente na documentação: a API "atualmente oferece suporte à residência de dados apenas nos Estados Unidos e não é compatível com Zero Data Retention (ZDR)", e escolher um sandbox auto-hospedado (self-hosted) não o torna elegível para ZDR. Se algum desses pontos for crítico para os seus requisitos de conformidade, migrar o sandbox para uma infraestrutura interna não mudará esse cenário.
As novidades do DevDay
Computer use. Adicione a ferramenta computer_use, habilite um desktop em um ambiente hospedado pela OpenAI e o agente passará a controlar um navegador hospedado. O guia de computer use estrutura o fluxo em torno de eventos de aprovação. O navegador solicita a aprovação do usuário antes de acessar qualquer nova origem de site, incluindo páginas públicas. Os logins chegam como solicitações separadas que a sua aplicação renderiza com campos para e-mail, senha e código de verificação; chaves de acesso (passkeys) e login via QR code não são suportados, e apenas o agente principal — e não um subagente — pode solicitar credenciais. A frase que merece atenção redobrada: "A aprovação de origem não impõe confirmação antes de ações individuais". Para compras ou alterações destrutivas, a documentação recomenda restringir o navegador hospedado a recursos que não possam executá-las, ou usar um runtime de navegador sob o seu próprio controle. O resumo do DevDay cita o computer use "por meio da API e no Codex e ChatGPT Work nos planos Pro 500 e Enterprise".
Bedrock Managed Agents, powered by OpenAI. A OpenAI e a Amazon reuniram "os recursos essenciais da Agents API" e adicionaram customizações para que funcionem nativamente na AWS. A página de produto da AWS o lista em versão de prévia (preview) e afirma que o runtime do agente e a inferência do modelo permanecem dentro da AWS, com cada agente possuindo sua própria identidade e permissões no ecossistema AWS.
Dots sobre o mesmo harness. O Decrypt relata que o harness do Codex "agora impulsiona os dots e é open source". Dots são os agentes sempre ativos do ChatGPT, cada um com seu próprio computador em nuvem, e nosso artigo explicativo sobre os dots detalha seus pontos fortes.
Dessa forma, um único loop agora executa um agente de programação, uma sessão de API, um agente na AWS e um assistente sempre ativo. O harness está convergindo. Os eventos de aprovação são a parte que recai diretamente sobre a equipe: cada um deles é uma pergunta dentro de uma sessão, respondida por quem quer que esteja com a transmissão (stream) aberta. Quando cinco sessões estiverem demandando aprovações ao mesmo tempo, alguém precisará decidir quem tem permissão para aprovar qual origem e onde essa decisão fica registrada. Esse é um problema de portões de aprovação (approval gates), e nós analisamos a versão aplicada ao Computer em Diretrizes de segurança para o computer use no GPT-6 Astra.
O que ela não gerencia: a camada de equipe
Uma sessão conhece apenas a si mesma. Ela não sabe que outras três sessões estão modificando o mesmo repositório, ou que o resultado de uma quarta está parado, sem revisão, desde terça-feira. Esses são problemas de gestão, e eles surgem no momento em que mais de uma pessoa começa a rodar mais de um agente.
Cinco perguntas que a API deixa em aberto, por concepção:
- Quem atribuiu isso e para qual ticket? Uma sessão possui um ID e quaisquer metadados que seu código registrar nela. Um responsável, uma Sprint ou um link para a issue de origem só existem se você os incluir explicitamente.
- Qual repositório e branch foram alterados? O diff precisa ser levado para algum lugar onde uma pessoa revisora possa analisá-lo.
- O que foi concluído, o que falhou e o que está aguardando? Os eventos são transmitidos enquanto você os escuta ou chegam via webhook. Nada é consolidado em uma fila de resultados aguardando uma pessoa.
- Quem valida o resultado? Um evento de aprovação cobre o acesso a um site ou um login, não a entrega do trabalho. "A sessão terminou" e "uma pessoa analisou as evidências e aprovou" passam a ser o mesmo evento, a menos que você construa o segundo.
- E quanto aos agentes que não são da OpenAI? Usar o Claude Code para um tipo de tarefa e o Codex para outro significa lidar com dois modelos de sessão e dois lugares diferentes para monitorar.
É possível construir soluções para essas cinco questões sobre os eventos: um quadro de tarefas, um webhook, um campo de status, uma coluna de revisão. Mas aí alguém pergunta: "nós chegamos a publicar a correção da exportação?", e a resposta está perdida no histórico do terminal que ninguém salvou. Nosso post sobre gerenciamento de tarefas de agentes de IA aborda essa abordagem de desenvolvimento próprio.
Subagentes dentro de uma sessão ou Tarefas em um quadro?
O parâmetro max_concurrent_subagents é a resposta da API para o paralelismo — e uma excelente solução para o perfil certo de trabalho. É o mesmo compromisso sobre o qual escrevemos quando o Codex aumentou seu limite de subagentes para 64: os subagentes compartilham uma sessão-pai, consolidam suas respostas em um único retorno e são revisados como um único resultado.
Use subagentes dentro de uma sessão quando as etapas envolverem predominantemente leitura, forem independentes e apenas a resposta combinada for relevante: pesquisar quatro APIs, varrer uma base de código em busca de um padrão, reunir evidências para investigar um incidente.
Use Tarefas separadas quando cada parte escrever código que precise de revisão individual: uma migração, uma funcionalidade em um módulo específico, uma correção que altere um arquivo compartilhado. No Sharkly, cada execução recebe seu próprio git worktree isolado em um Computador sob o seu controle, e cada resultado retorna para sua respectiva Tarefa acompanhado de seu diff, log de execução e revisor. Quatro alterações pesadas de escrita compactadas em um único resumo de subagente significam quatro decisões escondidas dentro de uma.
Perguntas frequentes
Em qual modelo o computer use funciona? Os exemplos da documentação utilizam o gpt-6-astra. Consulte o guia antes de presumir que outro modelo funcione com a ferramenta computer_use.
O Sharkly executa sessões da Agents API? O Sharkly executa agentes de programação de linha de comando (CLI) instalados nos seus Computadores, como o Codex e o Claude Code, na forma de Runtimes. As sessões da Agents API são um serviço hospedado, e não um Runtime instalado localmente; portanto, devem ser tratadas como um caminho de execução distinto.
Onde ocorre a revisão humana? Na Agents API, onde você decidir implementá-la: os eventos de aprovação cobrem acesso a sites e login, não a validação da entrega. No Sharkly, um Agente pode deixar sua Tarefa aguardando revisão humana, a solicitação cai na Inbox da pessoa responsável, e ela atualiza o status após analisar a resposta, o log de execução e o diff.
O papel de cada camada na arquitetura
Uma sessão persistente na infraestrutura da OpenAI é o componente mais conveniente deste lançamento — e também o que gera maior aprisionamento tecnológico (lock-in). Para uma equipe de engenharia, isso é fundamental: o agente de programação mais avançado muda constantemente, e um time cujos estados de revisão e regras de atribuição estão acoplados ao armazenamento de sessões de um único provedor é obrigado a reconstruir todo o seu fluxo de trabalho a cada mudança de liderança tecnológica.
Se você estiver desenvolvendo um produto ou serviço de backend baseado em agentes, a Agents API é a camada ideal, e o Bedrock Managed Agents representa essa mesma proposta para equipes que necessitam de execução interna na AWS. Você ganha o harness sem precisar mantê-lo e tem sandboxes prontos sem precisar provisioná-los. Você talvez nem precise de um quadro de tarefas; a sua própria aplicação cumpre esse papel.
Por outro lado, se os seus agentes atuam como membros da equipe na sua própria base de código — operados por pessoas, revisados por pessoas e entregues por meio dos seus repositórios e rastreadores habituais —, a equação é outra. O Codex e o Claude Code cuidam da execução. O Sharkly gerencia a atribuição no nível de equipe, os Computadores conectados, o contexto das tarefas, o progresso, os bloqueios, as entregas e a revisão humana entre essas ferramentas. Ele não substitui nenhum dos Runtimes, tampouco a Agents API. Essa mesma reflexão sobre posicionamento agora se aplica ao próprio Codex, tema que abordamos em Codex na nuvem versus seus próprios Computadores.
Contrate o harness se você estiver construindo um agente. Mas mantenha a camada de gestão sob o seu controle e neutra em relação a provedores se você estiver gerenciando um time deles.
Se você já opera múltiplos agentes, o Sharkly oferece um ponto centralizado para gerenciar suas tarefas e resultados. O Sharkly não comercializa tokens: o consumo dos modelos continua operando por meio das assinaturas ou chaves de API configuradas nas ferramentas que você conecta.
