A OpenAI move o harness de execução de agentes para dentro da API Responses

O harness deixa de morar no cliente

A mudança estrutural central aqui é sobre onde o loop de execução roda. A OpenAI observa que, quando a API Responses é usada com ferramentas personalizadas, ela "devolve o controle ao cliente, e o cliente precisa do próprio harness para executar as ferramentas". Com a ferramenta de shell e o container hospedado, esse harness passa a rodar no servidor.

O loop descrito é concreto: o modelo propõe um ou mais comandos de shell, a API os envia para um runtime de container, transmite a saída de volta e reinsere essa saída no contexto da próxima requisição. Isso se repete até o modelo retornar uma resposta final sem mais comandos. Nada nesse loop exige que o desenvolvedor rode um container, faça polling de saída ou monte a lógica de retentativas.

Para times de frontend e cliente, isso redefine o que é uma requisição. Um único prompt pode, segundo o post, "se transformar em um workflow completo" — descobrindo uma skill, buscando dados, transformando-os em SQLite, consultando-os e produzindo um artefato — sem que o cliente precise gerenciar nenhum estado intermediário.

Como o loop se mantém rápido e sob controle

Dois detalhes evitam que o loop trave ou sobrecarregue o contexto. Primeiro, o modelo pode propor múltiplos comandos de shell em uma única etapa, e a API os executa simultaneamente em sessões de container separadas, multiplexando os streams de saída independentes de volta como outputs estruturados da ferramenta. O exemplo dado: buscar arquivos, obter dados e validar resultados intermediários em paralelo.

Segundo, o modelo define um limite de saída por comando. A API aplica esse limite e retorna um resultado delimitado que preserva o início e o fim, marcando o conteúdo omitido — o post mostra um limite de 1.000 caracteres com um marcador "1000 chars truncated" no meio. É uma resposta deliberada ao antipadrão de tabelas grandes e logs de terminal consumindo o orçamento de contexto.

A própria ferramenta de shell é mais abrangente do que o interpretador de código focado apenas em Python já existente. Ela vem com grep, curl e awk prontos para uso, e o post afirma que ela pode rodar programas em Go ou Java ou iniciar um servidor NodeJS — ou seja, a superfície de execução é uma linha de comando Unix, não um runtime de uma única linguagem.

Compactação, e o ciclo de feedback do Codex que a construiu

Tarefas de longa duração enchem a janela de contexto, então a OpenAI adicionou a compactação nativa. Modelos treinados produzem um "item de compactação" que preserva o estado anterior em uma representação criptografada e eficiente em tokens; a próxima janela carrega esse item mais as partes de maior valor da anterior. Está disponível como compactação automática do lado do servidor, com um limite configurável, ou via um endpoint independente /compact, e a versão do servidor tolera pequenos excessos em vez de rejeitar requisições próximas do limite.

A afirmação mais específica do post é sobre como o sistema foi construído. O Codex tanto ajudou a construir o mecanismo de compactação quanto foi seu primeiro usuário:

Quando uma instância do Codex encontrava um erro de compactação, a gente colocava outra instância no ar para investigar. O resultado foi que o Codex ganhou um sistema de compactação nativo e eficaz só de trabalhar no problema.Montana Labs

A OpenAI apresenta isso como o Codex aprendendo junto com seus engenheiros. É também um sinal de como esses componentes são validados internamente antes de ir ao ar — o caminho de compactação é o mesmo que o Codex depende para sustentar sessões longas de programação.

O modelo de segurança que os desenvolvedores herdam em vez de reinventar

O acesso à rede do container passa por um proxy de saída sidecar: todas as requisições de saída passam por uma camada de política centralizada que aplica listas de permissão mantendo o tráfego observável. As credenciais usam injeção de segredos com escopo de domínio na saída — o modelo e o container veem apenas placeholders, e os valores reais dos segredos ficam fora do contexto visível ao modelo, sendo aplicados somente para destinos aprovados.

Essa é a parte que os times de cliente mais costumam errar ao construir seu próprio sandbox de agentes. Ao transferir o gerenciamento de credenciais e a política de rede para a plataforma, a OpenAI assume a responsabilidade pela superfície de vazamento e exfiltração que, de outra forma, ficaria na infraestrutura de cada desenvolvedor.

O que um desenvolvedor do lado do cliente agora precisa cuidar — e o que não precisa mais

A implicação concreta desse anúncio é uma redução do trabalho do cliente. Orquestração, execução em sandbox, truncamento de saída, compactação de contexto, política de rede e escopo de segredos agora são componentes da plataforma. Skills — pacotes de pastas versionados com um SKILL.md — permitem que os times empacotem padrões repetidos de múltiplas etapas como lógica reutilizável que o modelo descobre com comandos de shell simples como ls e cat.

O que continua do lado do desenvolvedor é o trabalho de design: preparar entradas no sistema de arquivos do container em vez do prompt, descrever tabelas SQLite para que o modelo consulte apenas as linhas relevantes, e criar skills que codificam convenções. O trade-off é claro: menos infraestrutura para manter, mas uma dependência maior do runtime da OpenAI e de seus modelos GPT-5.2 em diante, os únicos treinados para propor comandos de shell. Times que já construíram harnesses robustos precisam pesar o que perdem em portabilidade contra o que deixam de manter.