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

O harness deixa de residir no cliente

A mudança estrutural central está em onde o ciclo de execução passa a correr. A OpenAI nota que, quando a Responses API é usada com ferramentas personalizadas, esta "devolve o controlo ao cliente, e o cliente precisa do seu próprio harness para executar as ferramentas." Com a ferramenta de shell e o contentor alojado, esse harness passa para o lado do servidor.

O ciclo descrito é concreto: o modelo propõe um ou mais comandos de shell, a API encaminha-os para um runtime de contentores, transmite o resultado de volta e reinjeta esse resultado no contexto do pedido seguinte. Isto repete-se até o modelo devolver uma resposta final sem mais comandos. Nada nesse ciclo exige que o desenvolvedor corra um contentor, faça polling do resultado ou implemente novas tentativas.

Para equipas de frontend e de cliente, isto redefine o que é um pedido. Um único prompt pode, segundo a publicação, "expandir-se num fluxo de trabalho completo" — descobrindo uma skill, obtendo dados, transformando-os em SQLite, consultando-os e produzindo um artefacto — sem que o cliente detenha qualquer parte do estado intermédio.

Como o ciclo se mantém rápido e limitado

Dois detalhes evitam que o ciclo bloqueie ou sobrecarregue o contexto. Primeiro, o modelo pode propor vários comandos de shell num único passo, e a API executa-os em simultâneo em sessões de contentor separadas, multiplexando os fluxos de saída independentes de volta como resultados estruturados de ferramentas. O exemplo dado: pesquisar ficheiros, obter dados e validar resultados intermédios em paralelo.

Segundo, o modelo define um limite de output por comando. A API impõe esse limite e devolve um resultado limitado que preserva o início e o fim, assinalando o conteúdo omitido — a publicação mostra um limite de 1000 carateres com um marcador "1000 chars truncated" no meio. É uma resposta deliberada ao anti-padrão de tabelas grandes e logs de terminal que consomem o orçamento de contexto.

A própria ferramenta de shell é mais abrangente do que o interpretador de código existente, limitado a Python. Vem equipada com grep, curl e awk prontos a usar, e a publicação refere que consegue correr programas em Go ou Java ou iniciar um servidor NodeJS — ou seja, a superfície de execução é uma linha de comandos Unix, não um único runtime de linguagem.

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

As tarefas de longa duração enchem a janela de contexto, por isso a OpenAI adicionou compactação nativa. Modelos treinados para tal produzem um "item de compactação" que preserva o estado anterior numa representação encriptada e eficiente em tokens; a janela seguinte transporta esse item mais as partes de maior valor da janela anterior. Está disponível como compactação automática do lado do servidor, com um limiar configurável, ou através de um endpoint autónomo /compact, sendo que a versão do lado do servidor tolera pequenos excessos em vez de rejeitar pedidos próximos do limite.

A afirmação mais concreta da publicação é sobre como o sistema foi construído. O Codex tanto construiu o mecanismo de compactação como serviu de utilizador inicial:

Quando uma instância do Codex encontrava um erro de compactação, criávamos uma segunda instância para investigar. O resultado foi que o Codex passou a ter um sistema de compactação nativo e eficaz apenas por trabalhar no problema.Montana Labs

A OpenAI enquadra isto como o Codex a aprender juntamente com os seus engenheiros. É também um sinal sobre como estes primitivos são validados internamente antes de serem lançados — o percurso de compactação é o mesmo de que o Codex depende para sustentar sessões de programação longas.

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

O acesso à rede do contentor é gerido através de um proxy de saída sidecar: todos os pedidos de saída passam por uma camada de política centralizada que impõe listas de permissões mantendo o tráfego observável. As credenciais usam injeção de segredos delimitada por domínio no momento da saída — o modelo e o contentor veem apenas placeholders, e os valores reais dos segredos permanecem fora do contexto visível ao modelo, sendo aplicados apenas a destinos aprovados.

É esta a parte que as equipas de cliente mais frequentemente fazem mal ao construir a sua própria sandbox de agentes. Ao transferir a gestão de credenciais e a política de rede para a plataforma, a OpenAI está a assumir a responsabilidade pela superfície de fuga e exfiltração que, de outra forma, ficaria na infraestrutura de cada desenvolvedor.

O que um desenvolvedor do lado do cliente passa a gerir — e o que deixa de gerir

A implicação concreta deste anúncio é uma redução do papel do cliente. Orquestração, execução em sandbox, truncagem de output, compactação de contexto, política de rede e delimitação de segredos são agora primitivos da plataforma. As Skills — pacotes de pastas versionados com um SKILL.md — permitem às equipas empacotar padrões repetidos de vários passos como lógica reutilizável que o modelo descobre com comandos de shell simples como ls e cat.

O que permanece do lado do desenvolvedor é trabalho de design: preparar os inputs no sistema de ficheiros do contentor em vez de no prompt, descrever tabelas SQLite para que o modelo consulte apenas as linhas relevantes, e criar skills que codifiquem convenções. O compromisso é claro — menos infraestrutura para manter, mas uma dependência mais forte do runtime da OpenAI e dos seus modelos a partir do GPT-5.2, os únicos treinados para propor comandos de shell. As equipas que já construíram harnesses robustos devem ponderar o que perdem em portabilidade face ao que deixam de ter de manter.