OpenAI ha documentato il rollout di GPT-6 Astra e il suo utilizzo nella Responses API. Per chi sviluppa agenti AI, le novità più operative sono due: async tool calling, che consente al modello di proseguire parti del lavoro mentre l’applicazione esegue un tool lento, e mid-turn steering, che permette di inviare un aggiornamento dell’utente durante l’esecuzione di una risposta. (developers.openai.com)
Async tool calling: il modello non deve più attendere ogni tool
Nel flusso tradizionale, una function call interrompe il turno del modello fino al ritorno del risultato. Con GPT-6 Astra, una function o un custom tool può essere dichiarato con async: true: il modello emette la chiamata e può continuare a ragionare, avviare altre attività compatibili o rispondere alle parti indipendenti della richiesta. L’esecuzione concreta del tool, però, rimane responsabilità dell’applicazione: OpenAI non esegue né orchestra il job esterno al posto del team di sviluppo. (developers.openai.com)
Il risultato del job deve essere inviato in una richiesta successiva, associandolo al call_id originale. È il riferimento che collega una function_call alla corrispondente function_call_output, oppure una custom_tool_call alla relativa custom_tool_call_output. In pratica, il call_id diventa una chiave di correlazione da trattare come dato di stato del workflow, non come un dettaglio effimero della singola risposta. (developers.openai.com)
Implicazione operativa: separare risposta, job e risultato
L’interpretazione operativa è che un agente non possa più essere modellato soltanto come una sequenza lineare «prompt, tool, output». Servono almeno tre stati distinti:
- la risposta del modello che ha generato la chiamata;
- il job applicativo, con stato di avvio, completamento o errore;
- il risultato associato al
call_id, consegnato alla continuazione corretta della conversazione.
La guida suggerisce inoltre di aggiornare il riferimento alla risposta più recente quando arrivano nuovi turni prima della conclusione del job, mantenendo però il call_id iniziale. Per l’avvio anticipato, il job può partire non appena lo streaming consegna l’elemento di chiamata completo. (developers.openai.com)
Il pattern del wait tool: attendere solo quando il dato serve
OpenAI descrive anche un pattern applicativo con un tool sincrono di attesa. L’agente può lanciare più richieste asincrone, svolgere lavoro che non dipende dai loro risultati e invocare un tool di attesa solo quando deve usare quei dati. Questo tool non è nativo: schema, gestione dei job e semantica di attesa restano a carico dell’applicazione. (developers.openai.com)
Per rendere il pattern osservabile, la documentazione propone un task_handle univoco nella conversazione, associato internamente al call_id e al job in esecuzione. È utile conservarlo anche dopo il completamento, per distinguere richieste ripetute o risultati ricevuti in ritardo. (developers.openai.com)
Limiti documentati per i tool asincroni
L’async tool calling è supportato da GPT-6 Astra e dai modelli successivi. Riguarda function e custom tool eseguiti dall’applicazione, non gli strumenti hosted. La guida indica inoltre di non configurarlo con Programmatic Tool Calling e di non combinarlo con parallel tool calls nella modalità multi-agent. Sono vincoli da verificare direttamente nel progetto prima di estendere un harness esistente. (developers.openai.com)
Mid-turn steering: correggere il lavoro mentre è in corso
Il mid-turn steering consente di inviare nuove istruzioni utente senza attendere la fine della risposta. Per GPT-6 Astra, la funzionalità è disponibile nella Responses API tramite connessione WebSocket. Dopo l’evento response.created, il client invia response.steer sulla stessa connessione, usando l’ID della risposta come previous_response_id. (developers.openai.com)
Questa capacità è utile nei workflow in cui l’utente può modificare requisiti mentre l’agente prepara un piano, analizza documenti o coordina tool: per esempio, restringere il perimetro, cambiare una priorità o aggiungere un vincolo di output.
Ci sono però confini chiari. Lo steering non riscrive il contenuto già ricevuto dall’applicazione, non annulla azioni già eseguite e non cancella tool già avviati. Un aggiornamento accettato viene prima accodato; se la risposta iniziale viene interrotta, può terminare come incompleta con motivo steered, mentre il sistema crea una continuazione che incorpora l’aggiornamento. (developers.openai.com)
Risultati tool e steering devono convivere nello stesso stato
Quando una risposta necessita ancora di un risultato tool o di un’approvazione lato client, lo steering resta in coda. L’applicazione deve proseguire il normale flusso di consegna del risultato sulla stessa connessione. La documentazione avverte anche che gli aggiornamenti accodati esistono solo nella connessione WebSocket corrente: vanno registrati e riconciliati prima di tentare un replay dopo una disconnessione. (developers.openai.com)
L’implicazione operativa è importante: una correzione in corsa non sostituisce un sistema di controllo delle azioni. Se un tool può produrre effetti esterni, il workflow deve mantenere idempotenza, audit degli eventi e controlli applicativi sulle operazioni irreversibili. Questa è una raccomandazione di progettazione, non una garanzia fornita dalla funzionalità di steering.
Test di affidabilità da inserire prima del rilascio
L’introduzione di asincronia e correzioni in corso amplia il numero di condizioni da testare. Una suite minima dovrebbe includere:
- Risultati tardivi: verificare che il risultato di un job venga riconciliato con il
call_idoriginario anche dopo altri turni conversazionali. - Ordine variabile: simulare più tool con tempi di completamento diversi e controllare che l’agente non usi un dato prima della sua disponibilità.
- Ripetizioni e retry: assicurare che una riconsegna o un retry non producano due volte lo stesso effetto esterno.
- Steering durante tool in corso: verificare che il sistema spieghi correttamente ciò che è già stato avviato e ciò che verrà ricalcolato nella continuazione.
- Disconnessioni WebSocket: registrare gli steering accettati, gli ID di risposta, gli ID di steering e i risultati tool; non presumere che gli input in coda sopravvivano alla riconnessione.
- Compatibilità dell’harness: controllare esplicitamente i vincoli relativi a hosted tools, Programmatic Tool Calling e modalità multi-agent.
Cosa cambia per i team che gestiscono agenti AI
GPT-6 Astra sposta parte della complessità dai prompt all’orchestrazione. Async tool calling può ridurre i tempi morti nei task con dipendenze parziali; mid-turn steering rende l’interazione più adattabile. Nessuna delle due funzioni elimina però la necessità di progettare stato, osservabilità e recupero dagli errori.
La priorità pratica è quindi trattare ogni workflow come un processo event-driven: conservare correlazioni tra risposta, call_id, job e steering; separare l’avvio di un’azione dalla sua conferma; testare eventi fuori ordine e disconnessioni. La disponibilità effettiva del modello e delle funzionalità va verificata sul proprio account e sulla configurazione API, perché il rollout è indicato come progressivo. (developers.openai.com)