O Agents API da OpenAI muda principalmente quem opera o loop do agente. Em vez de o aplicativo manter sozinho a sequência de chamadas ao modelo, o estado da sessão, a compactação de contexto, a recuperação após interrupções e a coordenação de subagentes, esse trabalho passa para um harness do Codex executado e mantido pela OpenAI. O aplicativo, porém, continua responsável por definir o que o agente pode fazer, quais ferramentas e dados ele recebe, como a experiência aparece ao usuário e, dependendo do ambiente escolhido, pela própria infraestrutura de execução.
Essa divisão é a chave para avaliar a novidade. O Agents API não transforma toda a arquitetura de um produto em um serviço gerenciado: ele terceiriza uma camada específica — o runtime de agência — e mantém o restante sob controle da aplicação. A OpenAI lançou o recurso em beta público em 10 de setembro de 2026. A documentação oficial resume a fronteira dizendo que a OpenAI gerencia sessões, orquestração, compactação de contexto e recuperação, enquanto o aplicativo fornece ferramentas e escolhe o ambiente de execução. Consulte o anúncio oficial e a visão geral do Agents API.
Resposta curta: o harness fica gerenciado, o produto não
O melhor modo de pensar no Agents API é separar três peças: harness, ambiente e servidor da aplicação. O harness é a instância hospedada pela OpenAI que executa o modelo, coordena o loop de ferramentas e mantém a sessão. O ambiente é onde comandos, código e arquivos são manipulados. O servidor da aplicação é o seu código: inicia tarefas, recebe eventos, conecta dados e ferramentas e aplica regras do produto.
Na prática, o Agents API pode eliminar uma grande quantidade de “cola” de orquestração, mas não elimina decisões de produto, segurança, autorização, integração ou infraestrutura. Essa distinção aparece explicitamente na arquitetura oficial.
O que passa a ficar no harness gerenciado
Loop do agente e continuidade da sessão
O harness chama o modelo, processa uso de ferramentas, mantém a sessão e permite que o trabalho continue entre turnos. Sessões são duráveis: o aplicativo pode voltar ao mesmo contexto sem reconstruir manualmente todo o histórico. A documentação também descreve recuperação e retomada do trabalho como parte do serviço gerenciado.
Compactação de contexto
Quando uma sessão se aproxima do limite de contexto, o Agents API pode compactar trabalho anterior para preservar o que é necessário à continuação. Isso reduz a necessidade de implementar uma camada própria de resumos, recortes de histórico e reconstrução de contexto para tarefas longas. Ainda assim, a qualidade das instruções, dos dados fornecidos e da política de memória da aplicação continua sendo responsabilidade do produto.
Coordenação de subagentes
O recurso multiagente permite dividir tarefas em partes independentes e delegá-las a subagentes, cada um com seu próprio contexto, enquanto o agente raiz reúne os resultados. Isso substitui boa parte do código que antes criava workers, controlava concorrência e reconciliava respostas. O ganho é maior em pesquisa, análise e programação, onde subtarefas podem realmente avançar em paralelo.
Seleção e uso de ferramentas dentro do loop
O harness decide quando acionar ferramentas já configuradas e pode usar mecanismos como busca de ferramentas e chamadas programáticas. Ele suporta ferramentas integradas, MCP e funções personalizadas. A nuance importante é que o harness gerencia o uso; o aplicativo continua definindo as capacidades. Um servidor MCP remoto pode ser chamado diretamente pelo harness, mas funções da aplicação ainda precisam de um handler seu para executar a ação e devolver o resultado.
Execução em sandbox, quando você escolher o ambiente hospedado
Com environment.type: "openai_hosted", a OpenAI provisiona e gerencia o sandbox em que o agente pode executar código, editar arquivos e produzir artefatos. O aplicativo continua configurando os arquivos, pacotes e acesso de rede necessários. Se o ambiente for próprio, a fronteira muda: o harness continua gerenciado, mas a infraestrutura deixa de ser.
Comparação: quem cuida de cada camada
| Camada | Agents API / harness | Aplicativo |
|---|---|---|
| Loop do agente | Executa o ciclo de modelo, ferramentas, continuidade e retomada. | Define objetivos, instruções, limites e quando iniciar ou interromper trabalho. |
| Contexto | Mantém a sessão e faz compactação automática quando necessário. | Decide quais dados entram, política de retenção do produto e contexto de negócio. |
| Execução | Executa comandos diretamente em sandbox hospedado pela OpenAI. | Escolhe o ambiente; em self-hosted, provisiona, reconecta e encerra compute. |
| Arquivos | Manipula arquivos disponíveis no ambiente e pode produzir artefatos. | Fornece arquivos e decide persistência; em self-hosted, preservação é sua. |
| Ferramentas | Seleciona e chama ferramentas configuradas no loop. | Escolhe MCPs, funções e integrações; handlers de funções continuam no app. |
| Subagentes | Cria, coordena e acompanha trabalho delegado quando multiagente está habilitado. | Decide se usar multiagente, limites de concorrência, tarefas e políticas. |
| Observabilidade | Emite eventos, mantém histórico, registra uso e fornece traces no dashboard. | Consome eventos/webhooks, integra alertas e traduz telemetria em operação do produto. |
| Infraestrutura | Pode gerenciar o sandbox hospedado pela OpenAI. | Continua responsável por infraestrutura própria, rede privada, UX, backend e sistemas externos. |
O que continua sendo responsabilidade do app
Lógica de produto e experiência do usuário
O Agents API não decide quando uma tarefa deve existir, qual promessa o produto faz, como resultados aparecem, quais confirmações são necessárias ou o que fazer quando o agente falha. Filas, telas, notificações, estados de UI, limites de sessão por usuário e decisões de negócio continuam na aplicação.
Permissões, segurança e regras de negócio
Dar ao agente a capacidade de chamar uma ferramenta não significa delegar a política de autorização. O aplicativo ainda precisa decidir quais usuários podem acionar quais ações, validar parâmetros, aplicar controles de acesso, impor aprovações e limitar efeitos colaterais. Para operações sensíveis, o handler da ferramenta deve continuar sendo uma fronteira de segurança, e não apenas um proxy cego.
Ferramentas, dados e integrações
A OpenAI opera o harness, mas não conhece automaticamente seus bancos, CRMs, sistemas internos ou regras de domínio. Você precisa expor essas capacidades por MCP, funções ou outras integrações e escolher o que o agente enxerga. Em outras palavras, o Agents API substitui a orquestração do uso das ferramentas, não o trabalho de construir e governar as ferramentas.
Infraestrutura própria, quando houver
O Agents API permite ambientes hospedados pela OpenAI, de parceiros e self-hosted. No modo self-hosted, sua aplicação continua dona de provisionamento, reconexão, encerramento e preservação dos arquivos que precisarem sobreviver. A documentação recomenda esse caminho quando o agente precisa de infraestrutura privada, rede interna ou software específico.
Operação do produto em torno do agente
Eventos e webhooks ajudam a acompanhar o trabalho, mas o aplicativo ainda precisa tratar indisponibilidade de handlers, experiência de espera, idempotência de ações, retries de sistemas externos e políticas de cancelamento. Se uma função personalizada não responde, por exemplo, a sessão pode ficar aguardando o resultado. O runtime gerenciado não remove a necessidade de engenharia distribuída na borda do seu produto.
Observabilidade melhora, mas não vira uma plataforma de operação completa
O Agents API expõe eventos de sessão em tempo real, histórico salvo e uso registrado por turnos, inclusive para subagentes. O dashboard de tracing mostra respostas de modelo, chamadas de ferramentas, duração e status dos passos. Isso reduz o esforço para enxergar o que ocorreu dentro do loop e facilita depuração de agentes complexos. Veja a documentação de observabilidade e uso e de tracing.
Há, porém, limites importantes no beta público: traces detalhados ficam no dashboard, a API pública não oferece configuração de tracing nem exportadores externos, e a telemetria do agente ainda precisa ser correlacionada com logs, métricas e traces do seu próprio backend. Portanto, “observabilidade gerenciada” significa boa visibilidade do runtime do agente, não substituição automática do seu Datadog, Grafana, OpenTelemetry ou SIEM.
Quando o Agents API pode substituir orquestração própria
- Tarefas longas e iterativas: quando o agente precisa trabalhar por muitos passos, continuar entre turnos e lidar com crescimento de contexto.
- Uso intensivo de ferramentas: quando manter manualmente o loop de chamada, resultados e retomada já virou infraestrutura repetitiva.
- Subtarefas paralelizáveis: quando subagentes podem dividir pesquisa, análise, depuração ou geração de artefatos.
- Necessidade de sandbox: quando executar código e trabalhar com arquivos é parte natural da tarefa.
- Equipe que quer reduzir manutenção do harness: quando acompanhar mudanças de modelos, compactação e padrões de agentes não é diferencial do produto.
Nesses casos, a troca é clara: você abre mão de parte do controle sobre o runtime em troca de menos código de orquestração e de um harness que a OpenAI promete evoluir junto com os modelos.
Quando ele não substitui sua arquitetura
- Workflows determinísticos: se o processo é uma máquina de estados rígida, uma fila tradicional ou uma sequência auditável de etapas, um agente pode ser complemento, não substituto.
- Portabilidade entre provedores: se evitar dependência de um harness específico é requisito central, manter uma camada própria pode ser deliberado.
- Controle fino do compute: workloads com hardware especial, rede privada, compliance ou isolamento específico podem continuar em self-hosted — e, nesse caso, parte importante da operação permanece sua.
- Políticas de autorização complexas: o runtime não substitui o sistema de identidade, políticas e aprovações do produto.
- Observabilidade com exportação obrigatória: como o beta público não oferece exportadores de trace externos, equipes com requisitos rígidos podem precisar manter instrumentação adicional.
Critérios práticos para decidir a adoção
- Liste o código que hoje existe só para manter o agente rodando. Se há muita lógica de loop, estado, compaction, retries de sessão e subagentes, há forte sobreposição com o harness gerenciado.
- Separe “orquestração de agente” de “orquestração de negócio”. A primeira é candidata a migrar; a segunda normalmente deve continuar explícita no app.
- Escolha o ambiente antes de estimar a redução operacional. Com sandbox hospedado, você terceiriza também o compute da sessão. Com self-hosted, ainda administra a infraestrutura.
- Mapeie funções e MCPs. Ferramentas remotas podem se encaixar bem; funções locais e ações com efeitos colaterais exigem handlers robustos e autorização própria.
- Teste custo por tarefa, não só custo por chamada. Um agente pode fazer várias chamadas de modelo, usar subagentes, ferramentas e compute de sandbox. O Agents API não cobra uma taxa adicional pelo serviço em si no beta anunciado, mas tokens, ferramentas e contêineres seguem seus preços.
- Cheque requisitos de dados antes de produção. Em 13 de setembro de 2026, a documentação informa que o Agents API oferece residência de dados apenas nos Estados Unidos e não oferece Zero Data Retention, inclusive quando o sandbox é self-hosted.
Conclusão: a fronteira nova é entre runtime e produto
O Agents API substitui melhor a parte da stack que existe para fazer o agente continuar trabalhando: loop, sessão, contexto, recuperação, delegação e integração operacional com um ambiente de execução. Ele não substitui a parte que existe para fazer o produto ser correto: lógica de negócio, UX, identidade, permissões, governança, integrações, confiabilidade de handlers e decisões de infraestrutura.
Para equipes que já construíram um harness próprio, a pergunta útil não é “posso apagar minha orquestração?”, mas “quanto da minha orquestração é runtime genérico e quanto é comportamento específico do produto?”. Quanto maior a primeira parcela, maior a chance de o Agents API simplificar a arquitetura. Quanto maior a segunda, mais ele tende a entrar como uma camada gerenciada dentro de uma aplicação que continua explicitamente no comando.
