OpenAI sposta l'harness di esecuzione degli agenti nella Responses API

L'harness non vive più sul client

Il cambiamento strutturale principale riguarda dove viene eseguito il loop. OpenAI nota che quando la Responses API viene usata con tool personalizzati, "restituisce il controllo al client, e il client deve avere un proprio harness per eseguire i tool." Con il tool shell e il container ospitato, quell'harness si sposta sul server.

Il loop descritto è concreto: il modello propone uno o più comandi shell, l'API li invia a un runtime container, restituisce l'output in streaming e lo re-inietta nel contesto della richiesta successiva. Il ciclo si ripete finché il modello non restituisce un completamento senza ulteriori comandi. Niente in questo processo richiede allo sviluppatore di gestire un container, fare polling sull'output o costruire logiche di retry.

Per i team frontend e client, questo ridefinisce cos'è una richiesta. Un singolo prompt può, secondo il post, "espandersi in un workflow end-to-end"—scoprire una skill, recuperare dati, trasformarli in SQLite, interrogarli e produrre un artefatto—senza che il client gestisca alcuno stato intermedio.

Come il loop resta rapido e limitato

Due dettagli evitano che il loop si blocchi o inondi il contesto. Primo, il modello può proporre più comandi shell in un solo step, e l'API li esegue in parallelo in sessioni container separate, multiplexando gli stream di output indipendenti come output strutturati dei tool. L'esempio citato: cercare file, recuperare dati e validare risultati intermedi in parallelo.

Secondo, il modello imposta un limite di output per comando. L'API lo applica e restituisce un risultato limitato che conserva inizio e fine segnalando il contenuto omesso—il post mostra un limite di 1.000 caratteri con un indicatore "1000 chars truncated" al centro. È una risposta deliberata all'anti-pattern delle tabelle enormi e dei log da terminale che consumano il budget di contesto.

Il tool shell in sé è più ampio del code interpreter esistente, limitato a Python. Include di serie grep, curl e awk, e il post afferma che può eseguire programmi Go o Java o avviare un server NodeJS—quindi la superficie di esecuzione è una riga di comando Unix, non un singolo runtime linguistico.

La compattazione, e il ciclo di feedback di Codex che l'ha costruita

I task lunghi riempiono la finestra di contesto, quindi OpenAI ha introdotto la compattazione nativa. I modelli addestrati producono un "compaction item" che conserva lo stato precedente in una rappresentazione cifrata ed efficiente in token; la finestra successiva porta con sé quell'item più le parti di maggior valore di quella precedente. È disponibile come compattazione automatica lato server con una soglia configurabile, oppure tramite un endpoint standalone /compact, e la versione lato server tollera piccoli sfondamenti invece di rifiutare le richieste vicine al limite.

L'affermazione più specifica del post riguarda come è stato costruito il sistema. Codex ha sia costruito il meccanismo di compattazione sia agito da suo primo utente:

Quando un'istanza di Codex incontrava un errore di compattazione, ne avviavamo una seconda per indagare. Il risultato è stato che Codex ha ottenuto un sistema di compattazione nativo ed efficace semplicemente lavorando sul problema.Montana Labs

OpenAI descrive questo come Codex che apprende insieme ai suoi stessi ingegneri. È anche un segnale su come questi elementi primitivi vengono validati internamente prima del rilascio—il percorso di compattazione è lo stesso da cui dipende Codex per sostenere sessioni di coding lunghe.

Il modello di sicurezza che gli sviluppatori ricevono invece di reinventare

L'accesso di rete dei container è gestito tramite un proxy di egress sidecar: tutte le richieste in uscita passano attraverso un livello centralizzato di policy che applica allowlist mantenendo il traffico osservabile. Le credenziali usano un'iniezione di segreti scoped per dominio all'egress—il modello e il container vedono solo dei placeholder, e i valori reali dei segreti restano fuori dal contesto visibile al modello, applicati solo per destinazioni approvate.

Questo è l'aspetto che i team client sbagliano più spesso quando costruiscono la propria sandbox per agenti. Spostando la gestione delle credenziali e delle policy di rete sulla piattaforma, OpenAI si assume la responsabilità della superficie di leak ed esfiltrazione che altrimenti risiederebbe nell'infrastruttura di ogni singolo sviluppatore.

Cosa resta in mano a chi sviluppa lato client—e cosa no

L'implicazione concreta di questo annuncio è un restringimento del compito del client. Orchestrazione, esecuzione in sandbox, troncamento dell'output, compattazione del contesto, policy di rete e scoping dei segreti sono ora primitive di piattaforma. Le Skill—bundle di cartelle versionate con un SKILL.md—permettono ai team di incapsulare pattern multi-step ricorrenti come logica riutilizzabile che il modello scopre con semplici comandi shell come ls e cat.

Ciò che resta in capo allo sviluppatore è il lavoro di design: preparare gli input nel filesystem del container invece che nel prompt, descrivere le tabelle SQLite in modo che il modello interroghi solo le righe rilevanti, e scrivere skill che codifichino le convenzioni. Il compromesso è chiaro—meno infrastruttura da gestire, ma una dipendenza più forte dal runtime di OpenAI e dai suoi modelli GPT-5.2 e successivi, gli unici addestrati a proporre comandi shell. I team che hanno già costruito harness solidi dovrebbero valutare cosa perdono in termini di portabilità rispetto a cosa smettono di dover mantenere.